Phantom Payment
実際には支払いを受け取らないが invoice を発行する役割を担う Phantom node を導入
仮想的な node な感じがするけど、実際の node
Introducing Phantom Node Payments | Lightning Dev Kit Documentation
Phantom node に複数の node がチャネルをはる
これらはすべて 1 payee によって管理されている
payer は pahntom node あての invoice を発酵する
このときに hint でぶら下がっている node に振り分けることができる
ぶら下がっているノードは phantom node あての payment を受け取ることになるが、phantom の鍵を使って decrypt することで実際には phantom に支払いをせずに自分への支払いを受け取る
MPP に対応できない
モバイルを Phantom node にして、接続ノードをサーバー側にユーザーが管理するノードとするアーキテクチャはありえないか?
署名を分離するという考えではなくて、オンラインでなければならない処理だけをサーバーに置くというアーキテクチャにする方向性
LN async payment と同じでは?
non-custodial mobile wallet を phantom node の位置においた冗長化はできないか?
Pay-to-Open 的な仕組みがあればできそう?
node をスケールアウトさせれらるなら必要ないのでは?
channel をスケールアウトできない
LND
lnmux
Core Lightning
Core Lightning v0.11.0: Channel Multiplexing, a New API, and Much More | by Blockstream | Blockstream Engineering Blog | Medium
これはちょっと違う気がする
Amboss Ghost Address
Introducing Ghost Addresses
Amboss サーバーが phantom invoice を発行する
route hint に payee node が含まれている
payee node は phantom invoice への支払いを検知する
amboss は 、payee node の htlc 処理を hunderhub が hook するようにしている。原理は phantom payment と同じ。
payee node は preimage を amboss サーバーから取得して受金を完了する
LSP 型の non-custodial wallet には応用はできないか、、、
invoice 発行と LSP 運営が同じであれば、LSP は preimage を知っていることになるので横取りできてしまう
invoice を発行するサービスが別であれば、non custodial と謳ってもいいのかもしれない